스타 스키마
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.
1. 개요
스타 스키마는 비즈니스 프로세스 데이터를 팩트와 차원으로 분리하는 데이터 모델이다. 팩트는 측정 가능한 정량적 데이터를, 차원은 팩트 데이터에 대한 설명적 속성을 포함한다. 팩트 테이블은 주요 데이터를, 차원 테이블은 디멘션의 값을 저장하며, 관계형 데이터베이스를 이용한 다차원 데이터베이스 구현의 일종이다. 스타 스키마는 쿼리 단순화, 빠른 집계, OLAP 시스템에서의 큐브 구축 등 여러 장점을 제공하며, 비정규화된 모델로 인해 쿼리 성능 향상에 기여한다.
더 읽어볼만한 페이지
스타 스키마 | |
---|---|
개요 | |
종류 | 데이터 웨어하우징 스키마 |
설명 | 사실 테이블을 중심으로 차원 테이블이 방사형으로 연결된 형태 |
특징 | 단순한 구조 빠른 쿼리 성능 데이터 중복 가능성 |
구성 요소 | |
사실 테이블 (Fact Table) | 중심 테이블 측정값 (수치 데이터)과 외래 키 포함 예: 판매량, 매출액, 주문 수량 |
차원 테이블 (Dimension Table) | 사실 테이블을 설명하는 속성 정보 포함 예: 제품, 고객, 시간, 지역 |
장점 | |
단순성 | 이해하기 쉽고 구현이 간단함 |
빠른 쿼리 성능 | 조인 연산 최소화 |
사용자 친화성 | 비즈니스 사용자가 이해하기 쉬움 |
단점 | |
데이터 중복 | 차원 테이블에 중복 데이터 존재 가능 |
데이터 무결성 문제 | 데이터 중복으로 인해 데이터 일관성 유지 어려움 |
차원 테이블 변경 어려움 | 차원 테이블 구조 변경 시 영향 범위가 큼 |
사용 시점 | |
데이터 분석 | 다양한 각도에서 데이터를 분석해야 할 때 |
보고서 작성 | 쉽고 빠르게 보고서를 작성해야 할 때 |
의사 결정 지원 | 빠르고 정확한 의사 결정을 지원해야 할 때 |
관련 스키마 | |
스노우플레이크 스키마 (Snowflake Schema) | 스타 스키마의 차원 테이블을 정규화한 형태 |
컨스텔레이션 스키마 (Constellation Schema) / 갤럭시 스키마 (Galaxy Schema) | 여러 개의 사실 테이블을 연결하여 복잡한 분석을 지원하는 형태 |
2. 모델
스타 스키마는 비즈니스 프로세스 데이터를 팩트(fact)와 차원(dimension)으로 분리하여 모델링한다. 팩트는 비즈니스에 대한 측정 가능하고 정량적인 데이터를 가지고 있으며, 차원은 팩트 데이터와 관련된 설명적인 속성이다. 팩트 데이터의 예로는 판매 가격, 판매 수량, 시간, 거리, 속도 및 무게 측정이 있다. 관련 차원 속성의 예로는 제품 모델, 제품 색상, 제품 크기, 지리적 위치 및 판매자 이름이 있다.[4]
차원이 많은 스타 스키마는 ''지네 스키마''라고도 불린다. 속성이 몇 개밖에 없는 차원을 가지면 쿼리에 많은 테이블 조인이 발생하고 스타 스키마를 사용하기가 더 어려워지지만, 유지 관리가 더 간단하다는 장점이 있다.
데이터 웨어하우스에서의 분석에 사용되는 팩트 테이블은 여러 개의 서로 다른 차원으로 구분된다. 팩트 테이블은 주요 데이터를 가지고 있는 반면, 디멘션 테이블은 상대적으로 크기가 작고, 디멘션의 각각의 값을 표현한다. 필요에 따라, 디멘션 테이블은 팩트 테이블과 결합된다.
디멘션 테이블은 단순한 기본 키를 가지고 있는 반면, 팩트 테이블의 기본 키는 관련 디멘션 키를 조합한 복합 키인 경우도 있다.
디멘션 테이블에 중복된 데이터를 포함시켜 제2 정규형에 머무르게 하는 것이 일반적이다. 반면 팩트 테이블은 제3 정규형을 사용하는 경우가 많다.
스타 스키마는 관계형 데이터베이스를 이용한 다차원 데이터베이스의 구현의 일종이다. 전형적인 관계형 데이터베이스를 사용할 수 있기 때문에, 전용 다차원 데이터베이스를 사용하는 것보다 가격이나 편의성 측면에서 이점이 있다. 또한, 스타 스키마는 스노우플레이크 스키마의 일종이지만, 하나의 팩트 테이블과 계층 구조가 없는 디멘션 테이블을 사용하는 한, 쿼리를 단순화할 수 있다.
2. 1. 팩트 테이블
팩트 테이블은 특정 이벤트에 대한 측정값이나 지표를 기록한다. 팩트 테이블은 일반적으로 숫자 값과 설명 정보가 보관되는 차원 데이터에 대한 외래 키로 구성된다.[4]팩트 테이블은 낮은 수준의 균일한 세부 정보("세분성" 또는 "세분도"라고 함)로 설계되어 팩트가 매우 원자적인 수준에서 이벤트를 기록할 수 있다. 이로 인해 시간이 지남에 따라 팩트 테이블에 많은 수의 레코드가 누적될 수 있다. 팩트 테이블은 다음과 같은 세 가지 유형으로 정의된다.
- 트랜잭션 팩트 테이블은 특정 이벤트(예: 판매 이벤트)에 대한 팩트를 기록한다.
- 스냅샷 팩트 테이블은 특정 시점의 팩트(예: 월말 계정 세부 정보)를 기록한다.
- 누적 스냅샷 테이블은 특정 시점의 집계 팩트(예: 제품의 월별 누적 판매량)를 기록한다.
팩트 테이블에는 일반적으로 각 행을 고유하게 식별할 수 있도록 대체 키가 할당된다. 이 키는 단순 기본 키이다.
팩트 테이블은 데이터 웨어하우스에서의 분석에 사용되며, 여러 개의 서로 다른 차원으로 구분된다. 팩트 테이블은 주요 데이터를 가지고 있는 반면, 디멘션 테이블은 상대적으로 크기가 작고, 디멘션의 각각의 값을 표현한다. 필요에 따라, 디멘션 테이블은 팩트 테이블과 결합된다.
디멘션 테이블은 단순한 기본 키를 가지고 있는 반면, 팩트 테이블의 기본 키는 관련 디멘션 키를 조합한 복합 키인 경우도 있다.
2. 2. 차원 테이블
차원 테이블은 팩트 테이블에 비해 레코드 수가 비교적 적지만, 각 레코드는 팩트 데이터를 설명하기 위해 매우 많은 수의 속성을 가질 수 있다.[4] 차원은 다양한 특성을 정의할 수 있지만, 차원 테이블에서 정의되는 가장 일반적인 속성 중 일부는 다음과 같다.- 시간 차원 테이블은 스타 스키마에 이벤트가 기록되는 가장 낮은 수준의 시간 세분성을 설명한다.
- 지리 차원 테이블은 국가, 주 또는 도시와 같은 위치 데이터를 설명한다.
- 제품 차원 테이블은 제품을 설명한다.
- 직원 차원 테이블은 판매원과 같은 직원을 설명한다.
- 범위 차원 테이블은 보고를 단순화하기 위해 시간, 달러 값 또는 기타 측정 가능한 양의 범위를 설명한다.
차원 테이블은 일반적으로 대리 기본 키를 할당받으며, 일반적으로 단일 열 정수 데이터 유형이며 자연 키를 형성하는 차원 속성의 조합에 매핑된다.[4]
팩트 테이블은 데이터 웨어하우스에서의 분석에 사용되며, 여러 개의 서로 다른 차원으로 구분된다. 팩트 테이블은 주요 데이터를 가지고 있는 반면, 디멘션 테이블은 상대적으로 크기가 작고, 디멘션의 각각의 값을 표현한다. 필요에 따라, 디멘션 테이블은 팩트 테이블과 결합된다.
디멘션 테이블은 단순한 기본 키를 가지고 있는 반면, 팩트 테이블의 기본 키는 관련 디멘션 키를 조합한 복합 키인 경우도 있다.
디멘션 테이블에 중복된 데이터를 포함시켜 제2 정규형에 머무르게 하는 것이 일반적이다.
3. 장점
스타 스키마는 비정규화된 모델로, 트랜잭션 관계형 데이터베이스에 적용되는 일반적인 정규화 규칙이 완화되어 있다. 스타 스키마 비정규화의 장점은 다음과 같다.
- 더 간단한 쿼리: 스타 스키마 조인 로직은 일반적으로 고도로 정규화된 트랜잭션 스키마에서 데이터를 검색하는 데 필요한 조인 로직보다 간단하다.
- 간소화된 비즈니스 보고 로직: 고도로 정규화된 스키마와 비교하여 스타 스키마는 기간별 및 기준 보고와 같은 일반적인 비즈니스 보고 로직을 단순화한다.
- 쿼리 성능 향상: 스타 스키마는 고도로 정규화된 스키마와 비교하여 읽기 전용 보고 응용 프로그램의 성능을 향상시킬 수 있다.
- 빠른 집계: 스타 스키마에 대한 더 간단한 쿼리는 집계 작업의 성능 향상으로 이어질 수 있다.
- 큐브 공급: 스타 스키마는 모든 OLAP 시스템에서 독점적인 OLAP 큐브를 효율적으로 구축하는 데 사용된다. 실제로 대부분의 주요 OLAP 시스템은 독점적인 큐브 구조를 구축하지 않고도 스타 스키마를 소스로 직접 사용할 수 있는 ROLAP 작동 모드를 제공한다.
4. SQL 예제
체인점의 판매 데이터베이스를 예로 들어, 스타 스키마는 판매 데이터를 날짜, 상점 및 제품별로 분류할 수 있다. 오른쪽의 이미지는 스노우플레이크 스키마 문서에 제공된 샘플 스키마의 스타 스키마 버전이다.[1]
스타 스키마에서 Fact_Sales
는 팩트 테이블이고 Dim_Date
, Dim_Store
및 Dim_Product
의 세 개의 차원 테이블이 있다.[1] 각 차원 테이블은 Id
열에 기본 키가 있으며, 이는 Fact_Sales
테이블의 세 개의 열(복합) 기본 키(Date_Id
, Store_Id
, Product_Id
) 중 하나와 관련이 있다. 팩트 테이블의 기본 키가 아닌 Units_Sold
열은 계산 및 분석에 사용할 수 있는 측정 또는 메트릭을 나타낸다. 차원 테이블의 기본 키가 아닌 열은 차원의 추가 속성을 나타낸다(예: Dim_Date
차원의 Year
).[1]
4. 1. 쿼리 예제
sqlSELECT
P.Brand,
S.Country AS Countries,
SUM(F.Units_Sold)
FROM
Fact_Sales F
INNER JOIN Dim_Date D ON (F.Date_Id = D.Id)
INNER JOIN Dim_Store S ON (F.Store_Id = S.Id)
INNER JOIN Dim_Product P ON (F.Product_Id = P.Id)
WHERE
D.Year = 1997
AND P.Product_Category = 'tv'
GROUP BY
P.Brand,
S.Country
```
위 쿼리는 1997년에 각 브랜드 및 국가별로 TV가 얼마나 판매되었는지를 계산하는 예제이다. `Fact_Sales`는 팩트 테이블이며, `Dim_Date`, `Dim_Store`, `Dim_Product`는 각각 날짜, 상점, 제품에 대한 차원 테이블이다.

참조
[1]
논문
An Evaluation of the Challenges of Multilingualism in Data Warehouse Development
18th International Conference on Enterprise Information Systems - ICEIS 2016
[2]
웹사이트
DWH Schemas
http://www.dwhworld.[...]
2010-07-16
[3]
서적
An Introduction to Database Systems (Eighth Edition)
[4]
서적
The Data Warehouse Toolkit: The Complete Guide to Dimensional Modeling (Second Edition)
본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.
문의하기 : help@durumis.com